feat(payjoin): settings, DB v14 migration, and live status - #2477
Conversation
Adds is_aborted to payjoin_receivers/payjoin_senders and is_payjoin_enabled / payjoin_min_amount_sat / payjoin_expire_after_sec to settings, migrated in schema_13_to_14 with backfilled defaults (disabled, 10000 sat, 24h). PayjoinConstants gains the bounds and the documented 24h-expiry rationale. The bulk of the diff is the generated v14 schema snapshot; review the migration step, the table definitions, the seeds and the constants.
Threads the three new payjoin settings from the settings entity through the repository and datasource, fed by the DB columns added in the v14 migration.
Adds PayjoinStatus.aborted (a fallback broadcast: the payment landed as a plain transaction) and the isAborted model field, mapped to/from the new DB column and round-tripped in fromReceiverTable/fromSenderTable (fixing a pre-existing bug where isExpired/isCompleted were never mapped back, silently resetting a re-fetched session's status). The CSV export gains the matching aborted case so its status switch stays exhaustive. Entity getters logRef and canManuallyBroadcastOriginal are introduced here as the shared vocabulary the core engine (next) builds on.
Adds the payjoin settings screen (auto-saving toggle, min-amount and expiry with bounds-validating use-cases) reachable from bitcoin settings, wired through the settings cubit and locator. Includes all new payjoin l10n keys (settings + the send/receive/transactions keys the later feature PRs consume) so every stacked branch compiles standalone.
Adds a payjoinEnabledChangeStream to SettingsRepository (mirrors the existing currencyChangeStream pattern), emitted from setPayjoinEnabled, plus a WatchPayjoinEnabledChangesUsecase. Lets a live listener (the receive flow) react to the global setting changing without needing to leave and re-enter its screen.
Adds ServiceStatus.disabled (intentionally turned off, distinct from unknown/not-checked) and returns it for the payjoin service the moment the setting is off, instead of probing the OHTTP relay and painting the whole status page red for a feature the user isn't relying on. The status page shows it muted-grey with a "Disabled" label, and it no longer counts against allServicesOnline.
cc2d099 to
8a0e24c
Compare
|
Heads-up: force-pushed to fold the Why the new table lives here: the upcoming home-announcements feature (#<pj/07 PR number>) needs a persisted "dismissed announcements" table. Rather than ship a separate v15 migration stacked on top, we add the table to this PR's v14 migration — one schema bump instead of two, one Drift snapshot instead of two (~8k fewer generated lines across the two PRs). The table is created empty, so it's an additive, backfill-free change with no impact on the payjoin work in this PR. |
|
@claude audit this PR please |
|
Claude finished @ethicnology's task in 6m 57s —— View job Audit: feat(payjoin): settings, DB v14 migration, and live status
Verdict: no blocking issues found. The migration is additive and correct, the settings plumbing is consistent end-to-end, and the aborted/disabled semantics are coherent. A few forward-compat and polish items below. Should fix (or explicitly confirm PR2 covers it)1. 2. Deleted de/fr translations for still-live keys — Consider3. Debounced field edits are silently dropped on back-navigation — 4. Switch toggle is fire-and-forget — the 5. Forward-declared, currently-unused API — 6. Settings fetch failure reports payjoin as "offline" — Verified good
LimitationsNo Flutter toolchain is available in this runner, so I could not run |
2 participants
Adds the Drift v14 migration for payjoin, a reactive enabled/disabled setting (payjoinEnabledChangeStream), and a proper ServiceStatus.disabled value so the Status Services screen reports "Disabled" instead of "Offline"/"Unknown" when the user has turned payjoin off.
Relates to #782 (Allow user to view payjoin settings), #1584 (Default payjoin settings), #947 (Better Payjoin Status).
Merge order: 2nd, right after #2443. Base of PR2 (pj/01-core-engine). Must merge before PR2-PR5.
#2443 → PR1 (this) → PR2 → {PR3, PR4, PR5}